DSS Rel-18

 RAN1#109-e

9.9       Enhancement of NR Dynamic Spectrum Sharing (DSS)

Please refer to RP-213575 for detailed scope of the WI.

 

R1-2205576        Session notes for 9.9 (Enhancement of NR Dynamic Spectrum Sharing (DSS))               Ad-hoc Chair (CMCC)

 

R1-2204884        Work plan for Rel18 WI on Enhancement of NR Dynamic spectrum sharing (DSS)     Ericsson

9.9.1        NR PDCCH reception in symbols with LTE CRS REs

R1-2204885        NR PDCCH reception in symbols with LTE CRS REs         Ericsson

·        Support NR PDCCH reception in symbols overlapping with LTE CRS

Decision: The document is noted.

 

R1-2204709        Discussion on NR PDCCH reception in symbols with LTE CRS REs               MediaTek Inc.

·        Proposal 1: RAN1 adopts Table 1 as Rel-18 DSS simulation assumption for evaluation on the performance of puncturing PDCCH by LTE CRS

Parameters

Values

Carrier frequency

2 GHz / 3 GHz

SCS

15 kHz

PDCCH monitoring symbols

first 3 symbols / first 4 symbols

Bandwidth

5 MHz / 10 MHz /20 MHz

Channel model

TDL-A 30-10 / TDL-C 300-100

Correlation

low

Number of BS antennas

1 Tx / 2 Tx

Number of UE antennas

2 Rx / 4Rx

Channel estimation

TBD

CRS

4 port CRS

DCI payload (excluding CRC)

40 / 70 bits

Precoding

Precoder cycling per REG bundle

REG bundle size

6 PRBS

Decision: The document is noted.

 

R1-2203137         Discussion on NR PDCCH reception in symbols with LTE CRS REs     Huawei, HiSilicon

R1-2203210         Discussion on NR PDCCH reception for DSS             ZTE

R1-2203344         Discussion on NR PDCCH reception in symbols with LTE CRS Res     Spreadtrum Communications

R1-2203581         Discussion on PDCCH reception on CRS symbol       vivo

R1-2203648         Evaluation of NR PDCCH overlapping with LTE CRS              InterDigital, Inc.

R1-2203834         Discussion on NR PDCCH reception in symbols with LTE CRS REs     xiaomi

R1-2203923         Considerations on PDCCH receptions in symbols with LTE CRS            Samsung

R1-2204024         Discussion on NR PDCCH reception in symbols with LTE CRS REs     OPPO

R1-2204260         Discussion on NR PDCCH reception in symbols with LTE CRS REs     Apple

R1-2204323         Discussion on NR PDCCH reception in symbols with LTE CRS REs     CMCC

R1-2204395         Discussion on NR PDCCH reception in symbols with LTE CRS REs     NTT DOCOMO, INC.

R1-2204630         Discussion on NR PDCCH reception in symbols with LTE CRS REs     LG Electronics

R1-2204815         Discussion on NR PDCCH reception in DSS Intel Corporation

R1-2204823         NR PDCCH overlapping with LTE CRS        Nokia, Nokia Shanghai Bell

R1-2205049         NR PDCCH reception in symbols with LTE CRS REs               Qualcomm Incorporated

 

[109-e-R18-DSS-01] – Bishwarup (Intel)

Email discussion on NR PDCCH reception in symbols with LTE CRS REs by May 20

-        Check points: May 18

R1-2205173        Summary#1 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS Res               Moderator (Intel Corporation)

From May 12th GTW session

Agreement

To evaluate the following options:

·        Option-1-1: No NR-PDCCH-DMRS is transmitted for only the REs overlapping with LTE-CRS of the OFDM symbol, NR-PDCCH is punctured on REs colliding with LTE-CRS, NR-PDCCH must span at least 2 consecutive symbols with at least 1 symbol not overlapping with LTE-CRS

·        Option-1-2: No NR-PDCCH-DMRS is transmitted in any such RE of the OFDM symbol, NR-PDCCH is transmitted on REs not colliding with LTE-CRS including the original DMRS, NR-PDCCH is punctured on REs colliding with LTE-CRS, NR-PDCCH must span at least 2 consecutive symbols with at least 1 symbol not overlapping with LTE-CRS

·        Option-2: NR-PDCCH or NR-PDCCH-DMRS is transmitted on REs not colliding with LTE-CRS, NR-PDCCH and NR-PDCCH-DMRS may or may not be punctured on REs colliding with LTE-CRS

o   No puncture is baseline (UE side)

 

R1-2205174         Summary#2 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS REs               Moderator (Intel Corporation)

R1-2205356        Summary#3 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS REs               Moderator (Intel Corporation)

From May 16th GTW session

Observation

For evaluations consider the following options:

·        Option 1-1:

o   PDCCH and PDCCH DMRS mapping to REs: Legacy

o   PDCCH REs overlapping with LTE CRS: Receiver punctures

o   PDCCH DMRS REs overlapping with LTE CRS: All DMRS REs on overlapping symbol Not used for CE, or legacy pattern is assumed

o   gNB transmits: Irrelevant what the gNB transmits on REs overlapping with the LTE CRS REs as indicated in the CRS RM pattern.

o   Channel estimator: operate on clean symbol DMRS only, Legacy

·        Option 1-2:

o   PDCCH and PDCCH DMRS mapping to REs: New PDCCH rate-matching

§  No PDCCH DMRS on the symbol overlapping with LTE CRS

o   PDCCH REs overlapping with LTE CRS: Receiver punctures

o   PDCCH DMRS REs overlapping with LTE CRS: Not expected

o   Channel estimator (UE assumption): Operate on clean symbol DMRS only

o   gNB transmits: Irrelevant what the gNB transmits on REs overlapping with the LTE CRS REs as indicated in the CRS RM pattern

·        Option 2:

o   PDCCH and PDCCH DMRS mapping to REs: Legacy

o   PDCCH REs overlapping with LTE CRS: Baseline: Process as legacy

o   PDCCH DMRS REs overlapping with LTE CRS: Aware or unaware

o   Channel estimator: Baseline: Process as legacy (Receiver does not puncture DMRS), Optional: Advanced receiver (Use the DMRS other than legacy behavior)

o   gNB transmits:

§  Baseline: may puncture the PDCCH/PDCCH DMRS, or may superposition the two.

§  Optional: may puncture LTE CRS of Port#2&3.

§  Impact to LTE UEs should be considered if superposition is used.

 

R1-2205357        Summary#4 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS REs               Moderator (Intel Corporation)

From May 19th GTW session

Agreement

For evaluations consider the following list of scenarios:

·        Scenario#1A: 1 symbol CORESET, overlapped with CRS – Option 2 only

·        Scenario#2: 2 symbols CORESET, including 1 overlapping symbol and 1 clean symbol – Option 1-1/1-2/2

·        Scenario#3: 3 symbols CORESET, including 1 overlapping symbol and 2 clean symbols – Option 1-1/1-2/2

 

Agreement

LLS simulations assumptions, [] are optional:

 

Parameters

Values

Carrier frequency

2 GHz

SCS

15 kHz

Bandwidth

20 MHz [5, 10 MHz], LTE bandwidth equal or smaller than NR

Channel model

TDL-C 300, [TDL-A 300]

Correlation

Low

Number of BS antennas

4 Tx, (M,N,P,Mg,Ng;Mp,Np)= (1,2,2,1,1;1,1),

[2 Tx, (M,N,P,Mg,Ng;Mp,Np)= (1,1,2,1,1;1,1).]

Number of UE antennas

2 Rx (M,N,P,Mg,Ng;Mp,Np)= (1,1,2,1,1;1,1)

DCI payload (excluding CRC)

60 bits [50bits]

Interleaving

Non-Interleaved, [Interleaved]

Precoding

Precoder cycling per REG bundle

REG bundle size

6 PRBs

CRS

single 4 port CRS pattern, [additional 4 port CRS pattern]

Channel estimation

practical – companies to report details

UE speed

30 kmph [3kmph, 120 kmph, 350 kmph]

Power ratio of LTE-CRS RE/NR PDCCH RE, Power ratio of LTE-CRS RE/NR PDCCH-DMRS RE

Companies to report (if applicable)

 

Agreement

SLS simulations assumptions, [] are optional:

 

Parameters

Values

Carrier frequency

2.1 GHz

SCS

15 kHz

Simulation bandwidth

20 MHz [5, 10 MHz]，same as that in LLS

BS antenna height

25 m

UE height

1.5m

TRP transmit power

49 dBm 20 MHz

Scenario

Urban Macro (500m ISD), [Rma (1732m ISD)]

Device deployment

80% indoor, 20% outdoor (Uma) [50% indoor,50% in-car (Rma)]

UE speeds

Indoor users: 3km/h

Outdoor users (in-car): 30 km/h

BS noise figure

5 dB

BS antenna element gain

8 dBi

UE noise figure

9 dB

Thermal noise level

-174 dBm/Hz

Traffic geometry

Full Buffer

Macro sites

19

Downtilt

102° or according to Scenario

Minimum BS to UE distance

35m

KPI

Companies to report (e.g., total PDCCH capacity, PDCCH coverage/outage, Potential degradation of LTE, whether and how to achieve coexistence with legacy UEs)

Others

Companies to report (e.g., fraction of LTE UEs, fraction of Rel-18 DSS NR UEs, etc.). Companies to report considered baseline(s). Baseline(s) aim(s) to be comparable to the evaluated option(s)

 

Note: Email discussion for discussion and common assumption to be arranged.

·        Clarification of evaluation assumption

·        Template for collecting evaluation results

·        Sharing of the implementation assumption from companies

o   Dates: 13th – 17th June

9.9.2        UE support for two overlapping CRS rate matching patterns

R1-2203211        Discussion on support of two overlapping CRS patterns for DSS      ZTE

·        Proposal 1: For PDSCH transmission other than multi-DCI based MTRP, a new UE capability similar as FG 14-1a should be introduced to support two overlapping CRS rate matching patterns.

·        Proposal 2: For PDSCH transmission other than multi-DCI based MTRP, reuse the existing RRC parameters lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16 in ServingCellConfig.

·        Proposal 3: For PDSCH transmission other than multi-DCI based MTRP, UE does rate matching around REs indicated by both lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16.

Decision: The document is noted.

 

R1-2203582        Discussion on two overlapping CRS rate matching patterns              vivo

·        Proposal 1. Clarify that in this WID, the two overlapping CRS rate matching patterns are only applicable to PDSCH with 15kHz SCS scheduled by PDCCH with DCI format 1_1 or DCI format 1_2 with CRC scrambled with dedicated RNTI in non-MTRP case in FR1.

·        Proposal 2. To support two overlapping CRS rate matching patterns, the following options can be considered.

o   Option1. Reuse the lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16 and remove the restriction that lte-CRS-PatternList2-r16 is configured only when two different values are configured for coresetPoolIndex

o   Option2. Introduce new RRC parameters, e.g., lte-CRS-PatternList1-r17 and lte-CRS-PatternList2-r17, for this feature and corresponding descriptions in the spec.

·        Proposal 3. A new UE capability should be introduced to indicate the support of two overlapping CRS patterns. Only when the new capability is reported to gNB, can gNB configure two overlapping CRS patterns to UE for PDSCH rate matching for non-MTRP case.

Decision: The document is noted.

 

R1-2203138         Discussion on UE support for two overlapping CRS rate matching patterns               Huawei, HiSilicon

R1-2203345         Discussion on UE support for two overlapping CRS rate matching patterns               Spreadtrum Communications

R1-2203649         Supporting two overlapping CRS rate matching pattern            InterDigital, Inc.

R1-2203835         Discussion on UE support for two overlapping CRS rate matching patterns               xiaomi

R1-2203924         Two overlapping CRS rate matching patterns              Samsung

R1-2204025         Discussion on UE support for two overlapping CRS rate matching patterns               OPPO

R1-2204261         Discussion on UE supporting for two overlapping CRS rate matching patterns               Apple

R1-2204396         Discussion on LTE CRS rate matching pattern            NTT DOCOMO, INC.

R1-2204710         Discussion on supporting two overlapping CRS rate matching pattern   MediaTek Inc.

R1-2204824         Support for 2 overlapping CRS patterns        Nokia, Nokia Shanghai Bell

R1-2204886         UE support for overlapping CRS rate matching patterns           Ericsson

R1-2205050         UE support for two overlapping CRS rate-matching patterns    Qualcomm Incorporated

 

[109-e-R18-DSS-02] – Xianghui (ZTE)

Email discussion on UE support for two overlapping CRS rate matching patterns by May 20

-        Check points: May 18

R1-2205258        Feature lead summary #1 on UE support for two overlapping CRS rate matching patterns            Moderator (ZTE)

(May 12th GTW session)

 

R1-2205259        Feature lead summary #2 on UE support for two overlapping CRS rate matching patterns            Moderator (ZTE)

(May 16th GTW session)

 

R1-2205499        Feature lead summary #3 on UE support for two overlapping CRS rate matching patterns            Moderator (ZTE)

From May 19th GTW session

Working Assumption

Introduce two new RRC parameters (i.e., list3 and list4). gNB cannot configure legacy list1/2 and new list3/4 simultaneously. If new list3/4 are configured, UE applies list3/4 regardless of whether CORESETPoolIndex= 1 is configured for any of DL BWPs of the serving cell.

 

Working Assumption

·        Introduce two new RRC parameters lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 in ServingCellConfig around which the UE shall do rate matching for PDSCH scheduled by PDCCH with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI, or PDSCHs with SPS.

o   The network does not configure lte-CRS-PatternList3-r18 and any of lte-CRS-ToMatchAround, lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16 simultaneously. Lte-CRS-PatternList4-r18 is configured if lte-CRS-PatternList3-r18 is configured in ServingCellConfig.

o   For case when UE is not configured with two CORESET pools two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied

o   For case when UE is configured with two CORESET pools two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18

§  If UE is configured with crs-RateMatch-PerCoresetPoolIndex, lte-CRS-PatternList3-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘0’, and lte-CRS-PatternList4-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘1’

§  Otherwise, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied.

o   The legacy configuration rule in TS 38.331 is applied in Rel-18 DSS, i.e.,

§  “The first LTE CRS pattern in lte-CRS-PatternList4 shall be fully overlapping in frequency with the first LTE CRS pattern in lte-CRS-PatternList3, The second LTE CRS pattern in this list shall be fully overlapping in frequency with the second LTE CRS pattern in lte-CRS-PatternList31, and so on.”

Agreement

·        Introduce new UE capability(ies) for support of two overlapping LTE CRS patterns in Rel-18 DSS

o   NW can configure two LTE-CRS overlapping rate matching patterns without coresetPoolIndex only if the UE indicates support of the new capability(ies).

·        Clarify that the Rel-16 UE capability overlapRateMatchingEUTRA-CRS-r16 is subject to support of multiDCI-Multi-TRP-r16.

·        Maximum number of LTE-CRS rate matching patterns for PDSCH supported by a UE (i.e., maxNumberPatterns-r16 and maxNumberNon-OverlapPatterns-r16) is kept unchanged.

 

Final summary in R1-2205500.

9.9.33        Other

R1-2203836         Other issues on enhancement of NR Dynamic Spectrum Sharing            xiaomi

R1-2204332         Discussion on PDCCH reception with two overlapping CRS patterns for DSS     ZTE

R1-2204887         Other aspects related to DSS enhancements  Ericsson

R1-2204910         Discussion on additional evaluation results for NR PDCCH in collision with LTE CRS       Huawei, HiSilicon


 RAN1#110

9.9       Enhancement of NR Dynamic Spectrum Sharing (DSS)

Please refer to RP-221622 for detailed scope of the WI.

 

R1-2208149        Session notes for 9.9 (Enhancement of NR Dynamic Spectrum Sharing (DSS))               Ad-hoc Chair (CMCC)

 

[110-R18-DSS] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Ravi (Ericsson)

9.9.1        NR PDCCH reception in symbols with LTE CRS Res

R1-2205864         Discussion on NR PDCCH reception in symbols with LTE CRS REs     Huawei, HiSilicon

R1-2205964         Discussion on NR PDCCH reception for DSS             ZTE

R1-2206003         Discussion on NR PDCCH reception in symbols with LTE CRS REs     Spreadtrum Communications

R1-2206057         Discussion on PDCCH reception on CRS symbol       vivo

R1-2206324         Discussion on NR PDCCH reception in symbols with LTE CRS REs     OPPO

R1-2206432         NR PDCCH overlapping with LTE CRS        Nokia, Nokia Shanghai Bell

R1-2206658         Discussion on NR PDCCH reception in symbols with LTE CRS REs     Xiaomi

Withdrawn

R1-2206842         On PDCCH receptions in symbols with LTE CRS       Samsung

R1-2207011         Discussion on NR PDCCH reception in symbols with LTE CRS REs     MediaTek Inc.

R1-2207039         Discussion on NR PDCCH reception in symbols with LTE CRS REs     LG Electronics

R1-2207130         Evaluation of NR PDCCH overlapping with LTE CRS              InterDigital, Inc.

R1-2207249         NR PDCCH reception in symbols with LTE CRS REs               Qualcomm Incorporated

R1-2207347         Discussion on NR PDCCH reception in symbols with LTE CRS REs     Apple

R1-2207422         Discussion on NR PDCCH reception in symbols with LTE CRS Res     NTT DOCOMO, INC.

R1-2207439         NR PDCCH reception in symbols with LTE CRS REs               Ericsson

R1-2207591         Considerations on NR PDCCH for DSS         KT Corp.

 

R1-2207801        Summary#1 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS Res               Moderator (Intel Corporation)

R1-2207802        Summary#2 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS REs               Moderator (Intel Corporation)

R1-2207803        Summary#3 of AI: 9.9.1 NR PDCCH reception in symbols with LTE CRS REs               Moderator (Intel Corporation)

From Wed session

Agreement

If the feature “Reception of NR PDCCH candidates that overlap with LTE CRS REs “is supported, it is RAN1 understanding that the feature is supported by UE performing channel estimation with a regular legacy DMRS pattern in frequency dimension, i.e., no change to UE assumption on PDCCH DMRS RE positions/pattern in a symbol that are used for the purpose of channel estimation.

 

Agreement

Reception of NR PDCCH candidates that overlap with LTE CRS REs is supported by Rel18 UEs

PDCCH candidates and PDCCH-DMRS RE mapping are based on that of R15 from UE side.

Note: depends on UE capability

Following options can be used for PDCCH-DMRS channel estimation

 

Note: Restriction on the symbols and/or LTE CRS patterns applicable for above agreements can be considered during UE capability session.

 

Conclusion

RAN1 understands above agreements applies to 15kHz SCS only.

 

 

R1-2207865         Joint Proposal on enabling LTE CRS puncturing of NR PDCCH for Rel18 DSS Enhancements WI              Ericsson, Nokia, Nokia Shanghai Bell, NTT DOCOMO, Softbank, Telecom Italia

9.9.22        UE support for two overlapping CRS rate matching patterns

R1-2205865         Discussion on UE support for two overlapping CRS rate matching patterns               Huawei, HiSilicon

R1-2205965         Discussion on support of two overlapping CRS patterns for DSS            ZTE, China Telecom

R1-2206004         Discussion on UE support for two overlapping CRS rate matching patterns               Spreadtrum Communications

R1-2206058         Discussion on two overlapping CRS rate matching patterns      vivo

R1-2206325         Discussion on UE support for two overlapping CRS rate matching patterns               OPPO

R1-2206433         Support for 2 overlapping CRS patterns        Nokia, Nokia Shanghai Bell

R1-2206659         Discussion on UE support for two overlapping CRS rate matching patterns               Xiaomi

R1-2206843         Two overlapping CRS rate matching patterns              Samsung

R1-2207012         Discussion on supporting two overlapping CRS rate matching pattern   MediaTek Inc.

R1-2207131         Supporting two overlapping CRS rate matching patterns          InterDigital, Inc.

R1-2207250         UE support for two overlapping CRS rate matching patterns    Qualcomm Incorporated

R1-2207348         Disucssion on UE supporting for two overlapping CRS rate matching patterns               Apple

R1-2207423         Discussion on LTE CRS rate matching pattern            NTT DOCOMO, INC.

R1-2207440         UE support for overlapping CRS rate matching patterns           Ericsson

 

R1-2207842         Feature lead summary #1 on UE support for two overlapping CRS rate matching patterns Moderator (ZTE)

R1-2207843        Feature lead summary #2 on UE support for two overlapping CRS rate matching patterns            Moderator (ZTE)

From Wed session

Agreement

·        Introduce two new RRC parameters lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 in ServingCellConfig around which the UE shall do rate matching for PDSCH scheduled by PDCCH with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI, or PDSCHs with SPS.

o The network does not configure lte-CRS-PatternList3-r18 and any of lte-CRS-ToMatchAround, lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16 simultaneously. Lte-CRS-PatternList4-r18 is configured only if lte-CRS-PatternList3-r18 is configured in ServingCellConfig.

o For case when UE is not configured with two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied

o For case when UE is configured with two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18

§  If UE is configured with crs-RateMatch-PerCoresetPoolIndex, lte-CRS-PatternList3-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘0’, and lte-CRS-PatternList4-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘1’

§  Otherwise, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied.

o The legacy configuration rule in TS 38.331 is applied in Rel-18 DSS, i.e.,

§  “The first LTE CRS pattern in lte-CRS-PatternList4 shall be fully overlapping in frequency with the first LTE CRS pattern in lte-CRS-PatternList3, The second LTE CRS pattern in this list shall be fully overlapping in frequency with the second LTE CRS pattern in lte-CRS-PatternList3, and so on.”

 

The working Assumption made in RAN1#109e does not need to be confirmed.

Working Assumption(RAN1#109e)

·        Introduce two new RRC parameters lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 in ServingCellConfig around which the UE shall do rate matching for PDSCH scheduled by PDCCH with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI, or PDSCHs with SPS.

o The network does not configure lte-CRS-PatternList3-r18 and any of lte-CRS-ToMatchAround, lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16 simultaneously. Lte-CRS-PatternList4-r18 is configured if lte-CRS-PatternList3-r18 is configured in ServingCellConfig.

o For case when UE is not configured with two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied

o For case when UE is configured with two different values of coresetPoolIndex in ControlResourceSet, and configured with lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18

§  If UE is configured with crs-RateMatch-PerCoresetPoolIndex, lte-CRS-PatternList3-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘0’, and lte-CRS-PatternList4-r18 is applied if the PDSCH is associated with coresetPoolIndex set to ‘1’

§  Otherwise, both lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applied.

o The legacy configuration rule in TS 38.331 is applied in Rel-18 DSS, i.e.,

§  “The first LTE CRS pattern in lte-CRS-PatternList4 shall be fully overlapping in frequency with the first LTE CRS pattern in lte-CRS-PatternList3, The second LTE CRS pattern in this list shall be fully overlapping in frequency with the second LTE CRS pattern in lte-CRS-PatternList3, and so on.”

 

Agreement

lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are applicable to 15 kHz SCS PDSCH only.

 

Agreement

The following TP for sub-clause 5.1.4.2 of TS 38.214 h20 is endorsed in principle.

5.1.4.2              PDSCH resource mapping with RE level granularity

<omitted text>

A UE may be configured with any of the following higher layer parameters:

-     REs indicated by the 'RateMatchPatternLTE-CRS' in lte-CRS-ToMatchAround in ServingCellConfig or ServingCellConfigCommon configuring cell-specific RS, in 15 kHz subcarrier spacing applicable only to 15 kHz subcarrier spacing PDSCH, of one LTE carrier in a serving cell are declared as not available for PDSCH.

-     REs indicated by 'RateMatchPatternLTE-CRS' in lte-CRS-PatternList1-r16 or lte-CRS-PatternList3-r18 in ServingCellConfig configuring cell-specific RS, in 15 kHz subcarrier spacing applicable only to 15 kHz subcarrier spacing PDSCH, of one LTE carrier in a serving cell are declared as not available for PDSCH.

-     For the UE for broadcast reception, REs indicated by 'RateMatchPatternLTE-CRS' in PDSCH-Config-MCCH or PDSCH-Config-MCCH configuring cell-specific RS, in 15 kHz subcarrier spacing applicable only to 15 kHz subcarrier spacing PDSCH, of one LTE carrier in a serving cell are declared as not available for PDSCH.

-     Each RateMatchPatternLTE-CRS configuration contains v-Shift consisting of LTE-CRS-vshift(s), nrofCRS-Ports consisting of LTE-CRS antenna ports 1, 2 or 4 ports, carrierFreqDL representing the offset in units of 15 kHz subcarriers from (reference) point A to the LTE carrier centre subcarrier location, carrierBandwidthDL representing the LTE carrier bandwidth, and may also configure mbsfn-SubframeConfigList representing MBSFN subframe configuration. A UE determines the CRS position within the slot according to Clause 6.10.1.2 in [15, TS 36.211], where slot corresponds to LTE subframe.

-     If the UE is configured by higher layer parameter PDCCH-Config with two different values of coresetPoolIndex in ControlResourceSet and is also configured by the higher layer parameter lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16 in ServingCellConfig, the following REs are declared as not available for PDSCH:

-     if the UE is configured with crs-RateMatch-PerCoresetPoolIndex, REs indicated by the CRS pattern(s) in lte-CRS-PatternList1-r16 if the PDSCH is associated with coresetPoolIndex set to ‘0’, or the CRS pattern(s) in lte-CRS-PatternList2-r16 if PDSCH is associated with coresetPoolIndex set to ‘1’;

-     otherwise, REs indicated by lte-CRS-PatternList1-r16 and lte-CRS-PatternList2-r16, in ServingCellConfig.

-     If the UE is not configured by higher layer parameter PDCCH-Config with two different values of coresetPoolIndex in ControlResourceSet, and if the UE is configured by higher layer parameter lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 in ServingCellConfig, REs indicated by lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 are declared as not available for PDSCH.

-     If the UE is configured by higher layer parameter PDCCH-Config with two different values of coresetPoolIndex in ControlResourceSet and is also configured by the higher layer parameter lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18 in ServingCellConfig, the following REs are declared as not available for PDSCH:

-     if the UE is configured with crs-RateMatch-PerCoresetPoolIndex, REs indicated by the CRS pattern(s) in lte-CRS-PatternList3-r18 if the PDSCH is associated with coresetPoolIndex set to ‘0’, or the CRS pattern(s) in lte-CRS-PatternList4-r18 if PDSCH is associated with coresetPoolIndex set to ‘1’;

-     otherwise, REs indicated by lte-CRS-PatternList3-r18 and lte-CRS-PatternList4-r18, in ServingCellConfig.

<omitted text>

 

Agreement

·        Agree the following RRC parameters for support of two overlapping LTE-CRS patterns.

·        Send an LS to RAN2 about the agreed RRC parameters together with all RAN1 agreements in AI 9.9.2.

WI code

Sub-feature group

Parameter name in the spec

New or existing?

Description

Value range

Per (UE, cell, TRP, …)

UE-specific or Cell-specific

Specification

NR_DSS_enh

Support for two overlapping CRS rate matching patterns

lte-CRS-PatternList3

 

New

A list of LTE CRS patterns around which the UE shall do rate matching for PDSCH. The LTE CRS patterns in this list shall be non-overlapping in frequency. This list can be configured if [Rel-18 DSS capability(ies)] specified in TS 38.306 [26] is indicated. The network does not configure this field and lte-CRS-ToMatchAround, or this field and lte-CRS-PatternList1, or this field and lte-CRS-PatternList2 simultaneously.

LTE-CRS-PatternList-r16

ServingCellConfig

UE-specific

38.331

NR_DSS_enh

Support for two overlapping CRS rate matching patterns

lte-CRS-PatternList4

 

New

A list of LTE CRS patterns around which the UE shall do rate matching for PDSCH. The LTE CRS patterns in this list shall be non-overlapping in frequency. This list can be configured if [Rel-18 DSS capability(ies)] specified in TS 38.306 [26] is indicated. The first LTE CRS pattern in this list shall be fully overlapping in frequency with the first LTE CRS pattern in lte-CRS-PatternList3. The second LTE CRS pattern in this list shall be fully overlapping in frequency with the second LTE CRS pattern in lte-CRS-PatternList3, and so on. Network configures this field only if the field lte-CRS-ToMatchAround is not configured and the field lte-CRS-PatternList3 is configured.

LTE-CRS-PatternList-r16

ServingCellConfig

UE-specific

38.331

 

R1-2208193        [Draft] LS to RAN2 on two overlapping LTE-CRS patterns in Rel-18 DSS               ZTE

Decision: The draft LS is endorsed in principle by replacing

·        Clarify that the Rel-16 UE capability overlapRateMatchingEUTRA-CRS-r16 is subject to support of multiDCI-Multi-TRP-r16.

with

·        Clarify that the Rel-16 UE capability overlapRateMatchingEUTRA-CRS-r16 is subject to support of multiDCI-Multi-TRP-r16 in Rel-18 ASN.1.

Final LS is approved in R1-2208194.

 

Final summary in R1-2207844.


 RAN1#114-bis

8.10   Maintenance on Enhancement of NR Dynamic Spectrum Sharing (DSS)

R1-2310549         Session notes for 8.10 (Maintenance on enhancement of NR Dynamic Spectrum Sharing)         Ad-Hoc Chair (CMCC)

Friday decision: The session notes are endorsed and contents reflected below.

 

[114bis-R18-DSS] – Ravi (Ericsson)

Email discussion on NR DSS enhancement

-        To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

8.10.1    NR PDCCH reception in symbols with LTE CRS REs

R1-2308922         Maintenance of NR PDCCH reception in symbols with LTE CRS REs        Huawei, HiSilicon

R1-2309135         Maintenance of NR PDCCH reception in symbols with LTE CRS              ZTE

R1-2309622         Remaining issues for PDCCH reception in overlapping with LTE CRS       OPPO

R1-2310009         Remaining Issues on NR PDCCH Reception in Symbols with LTE CRS REs     Langbo

R1-2310045         Maintenance on NR PDCCH reception in symbols with LTE CRS REs        NTT DOCOMO, INC.

R1-2310096         Maintenance for reception of NR PDCCH candidates overlapping with LTE CRS REs            Ericsson

R1-2310155         NR PDCCH reception in symbols with LTE CRS REs              Qualcomm Incorporated

 

R1-2310361         Moderator Summary#1 for Rel. 18 eDSS   Moderator (Intel Corporation)

From Monday session

Agreement

·       Adopt the TP to Section 7.3.2.2, TS38.211.

------------------------------- start TP to 38.211 -----------------------

7.3.2.2      Control-resource set (CORESET)

<unchanged parts omitted>

-      if the higher-layer parameter precoderGranularity equals allContiguousRBs,

-      the UE may assume the same precoding being used across the all resource-element groups within the set of contiguous resource blocks in the CORESET;

-      the UE may assume that no resource elements in the CORESET overlap with an SSB;

-      if the UE is not provided with the higher-layer parameter pdcchCandidateReception-WithCRSOverlap, the UE may assume that no resource elements in the CORESET overlap with  LTE cell-specific reference signals as indicated by the higher-layer parameter lte-CRS-ToMatchAround, lte-CRS-PatternList1, or lte-CRS-PatternList2, or lte-CRS-PatternList3.

<unchanged parts omitted>

-------------------------------- end TP -----------------------------------

 

Agreement

·       Adopt the TP to Section10.1, TS38.213.

------------------------------- start TP to 38.213 -----------------------

10.1          UE procedure for determining physical downlink control channel assignment

< Unchanged parts are omitted >

When precoderGranularity = allContiguousRBs, a UE does not expect

-                 to be configured a set of resource blocks of a CORESET that includes more than four sub-sets of resource blocks that are not contiguous in frequency

-                 any RE of a CORESET to overlap with any RE determined from

-              lte-CRS-ToMatchAround or LTE-CRS-PatternList if the UE is not provided pdcchCandidateReception-WithCRSOverlap and the UE does not indicate an associated capability corresponding to the configuration of lte-CRS-ToMatchAround or of LTE-CRS-PatternList

-              a SS/PBCH block.

< Unchanged parts are omitted >

-------------------------------- end TP -----------------------------------

 

Agreement

·        Update the component 2 of FG52-1

2) Reception of a NR PDCCH candidate in REs that overlap with LTE CRS: candidate value set {

a) when at least one symbol of the NR PDCCH candidate and the DMRS for demodulation of the NR PDCCH candidate is not overlapped with LTE CRS,

b) when some or all of symbols of NR PDCCH candidate overlap with LTE CRS}

 

 

For the editors:

The above endorsed text proposals to TS 38.211 and 38.213, respectively, are also collected in R1-2310596. Please consider them in the next specification revision.

R1-2310596         Endorsed text proposals for TS38.211 and TS38.213 for Rel. 18 eDSS     Moderator (Intel Corporation)

8.10.22    UE support for two overlapping CRS rate matching patterns

No contributions.


 RAN1#115

8.10   Maintenance on Enhancement of NR Dynamic Spectrum Sharing (DSS)

R1-2312509         Session notes for 8.10 (Maintenance on enhancement of NR Dynamic Spectrum Sharing)         Ad-Hoc Chair (Huawei)

Friday decision: The session notes are endorsed and contents reflected below.

 

[115-R18-DSS] – Ravi (Ericsson)

Email discussion on NR DSS enhancement

-        To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

8.10.1    NR PDCCH reception in symbols with LTE CRS REs

R1-2311023         Maintenance of NR PDCCH reception in symbols with LTE CRS              ZTE

R1-2311274         Remaining issues for PDCCH reception in overlapping with LTE CRS       OPPO

R1-2311450         Monitoring of PDCCH candidates overlapping with LTE CRS              Nokia, Nokia Shanghai Bell

R1-2311696         Maintenance of NR PDCCH reception in symbols with LTE CRS              Apple

R1-2312219         Maintenance of NR PDCCH reception in symbols with LTE CRS REs        Huawei, HiSilicon

 

R1-2312367         Moderator Summary#1 for Rel. 18 eDSS   Moderator (Intel Corporation)

From Tuesday session

Agreement

The TP (Clause 7.3.2.2 of TS 38.211) for issue 3 in section 2.3 of R1-2312367 is endorsed.

8.10.22    UE support for two overlapping CRS rate matching patterns

None.